Co-authored-by: Philip Chimento <[email protected]>

The "timezone of an instant" is a misnomer because the `instant` type
doesn't carry timezone information. The host has a currently configured
time zone (or has no such concept, in which case the only sensible thing
to do is use UTC).

This flag is problematic because when a time zone is "in DST" is not well
defined. Most time zones in the world don't use DST at all. Of the ones
that do, most go to DST during the summer for half the year, but not all.

For example, the function in Moment.js that provides this functionality
comes with a giant caveat:
https://momentjs.com/docs/#/query/is-daylight-saving-time/

Other possibilities: "tzid", "iana-id", "identifier", "iana-identifier".

Returning a user-displayable name as part of timezone-display would
require more information: the user's preferred language, and the preferred
style for the name:
 - abbreviated or not
 - year-round or specific to the Instant
E.g., the time zone with the IANA id "America/Los_Angeles" might be
displayed as "Pacific Time", "Pacific Standard Time", "Pacific Daylight
Time", "PT", "PST", "PDT", "Nordamerikanische Westküstenzeit"...

The Rust iana_time_zone crate uses IANA time zone IDs, so if this
interface needs to be able to implement iana_time_zone, timezone-display
should have an IANA ID and not a user-displayable name.

There are time zones that used sub-minute or even sub-second UTC offsets
for instants in the past. E.g., when built using Vanguard format, the UTC
offset in the TZDB for "Asia/Ho_Chi_Minh" before July 1906 is
7:06:30.133333333.

If the timezone-display ID is an IANA ID, and we are going with the
approach of not making the localized ("PST" vs "PDT" vs "PT") name part of
this component, then the current time zone doesn't depend on the current
time.

After removing the isDST flag, timezone-display contains two pieces of
data, the ID and the UTC offset. The UTC offset is already available via
a function that takes an Instant as input. The ID could just be available
via its own function that doesn't take any input.

In that case there would be no need for timezone-display.

Instead of only specifying the epoch of the instant returned from now(),
specify the epoch of the instant type. It then follows that now()
returns an instant with that epoch.

Use types::duration for the return type of get-resolution instead. It
supports durations up to 584 years which is more than sufficient for any
clock resolution.

(A more capable duration type would be needed if we were doing any
arithmetic between instants.)